At the present time, various international standards bodies and consortiums, such as the Third Generation Partnership Project (3GPP), European Telecommunications Standards Institute (ETSI) and the International Telecommunications Union (ITU), are participating in initiatives for defining a Next Generation Network. According to ITU-T, the Next Generation Network (NGN) is a packet-based network able to provide services including Telecommunication Services and able to make use of multiple broadband, QoS-enabled transport technologies and in which service-related functions are independent from underlying transport-related technologies. The NGN offers unrestricted access by users to different service providers. It also supports generalized mobility which will allow consistent and ubiquitous provision of services to users.”
The Next Generation Network is generally based upon the Internet Multi-Media Sub-system (IMS) architecture, and utilizes Session Initiation Protocol (SIP) for managing the set-up and tear-down of communication sessions between parties. This arrangement is advantageous in that IMS/SIP provides a framework for Internet Protocol (IP) networks to establish multimedia sessions, including Voice over Internet Protocol (VoIP) phone calls, in a way that is fraud resistant, and which allows for the subsequent accounting and inter-domain settlements to be undertaken using methods very similar to those currently employed by Public Switched Telephone Network (PSTN) and cellular network operators. That is, users can be billed for each individual call/session with the charge related to the type of service delivered, and these charges can be properly distributed to each of the bearer networks (or administrative domains) traversed by the call/session.
As with the PSTN, it is envisaged that the NGN will consist of many operators/administrative domains, and the IMS architecture provides the basis for a subscriber of one operator to establish a voice call or multimedia session with a subscriber of another operator, with both operators (and any intermediate operators) reserving the necessary network resources in their respective administrative domains to support the Quality of Service (QoS) required for the bearer packet flows that carry the voice or multimedia streams associated with that session. Further, the IMS architecture fully supports the roaming of end users, with the visited domain supporting bearer flow QoS in the same fashion as the home domain would.
FIG. 1 schematically illustrates a representative Next Generation Network architecture. As in the PSTN and the Internet, the NGN is expected to be a conglomeration of multiple administrative domains' networks. An administrative domain's business may be primarily that of serving end customers or primarily that of providing transit to other administrative domains. For the purposes of this application, the network of a transit providing administrative domain is referred to as a Transit Network (TN)2. An administrative domain that serves end customers consists of two types of network: a core IP network (CN)4 and one or more attachment (or “access”) networks (ANs)6 that “attach” end customers' terminal equipment (TEs)8 to the core network4, via an Attachment Gateway 10, so that they can receive IMS service. ANs are normally considered to be in the same administrative domain as the CM they connect to, even when they are operated by a separate business entity (an AN operator) from whom the CN operator buys “wholesale access”. Note that while both Transit Networks and Core Networks route IP packets based upon the destination IP address in each packet's header, ANs transport packets between TEs and the attachment point of the CN, without regard to IP addresses. While an attachment network can be as simple as a wire or a Time Domain Multiplexed (TDM) circuit, it usually consists of a media specific first mile network and a more general packet backhaul network (in 3GPP wireless terminology this backhaul network is denoted by the term “core”, but it is still part of the AN, and not to be confused with the CN).
In the network architecture illustrated in FIG. 1, packets are transported between the various core and transit networks by Exchange Links 12 hosted by Transport Border Gateways (TBGs) 14 in each network. For any pair of networks an Exchange Link may be a physical link or some form of virtual circuit. Those skilled in the art will recognize that multiple networks can also be interconnected over a connectionless exchange Network (XN). An XN may range in scope from a single Ethernet switch to a global IP network or Virtual Private Network.
IMS is specified to use Session Initiation Protocol (SIP) to set up and take down multimedia calls or sessions. The IMS architecture specifies a number of Call State Control Functions (CSCFs) 16 distributed through the network that process and act upon the SIP messages. In the establishment of a specific session, SIP messaging needs to be processed by at least an originating Serving CSCF (S-CSCF) associated with the originator of the session, and a destination S-CSCF associated with the target or destination of the session set up. Usually however SIP clients do not peer directly with their associated S-CSCFs and there are intermediate CSCFs routing and forwarding SIP messages between SIP clients and their associated S-CSCFs, and between originating and destination CSCFs. Of particular relevance to the present application are the peer CSCFs responsible for forwarding SIP messages between administrative domains. In the present description we designate any CSCF that is the last one in an administrative domain to forward a SIP message to another domain, or the first in an administrative domain to receive a SIP message from another domain, as a border CSCF (b-CSCF). Those familiar with 3GPP and/or other NGN standards thrusts will recognize that there is some debate as to how border control functionality will be architected. The term “b-CSCF” is intended to encompasses such functional components as an interrogating-CSCF (I-CSCF), Interconnection Border Control Function (IBCF) and aspects of a Breakout Gateway Control Function (BGCF) Even an S-CSCF may be a b-CSCF when border control is not a strong operator requirement.
There are no CSCFs in attachment networks—the peer of the so called proxy-CSCF (P-CSCF) is actually the SIP client function of the terminal equipment. Since a SIP client, particularly in an application server (AS) 8b might peer directly with an S-CSCF, in the present description we use the term perimeter-CSCF (p-CSCF) to refer to the CSCF that is the first one/last one handling SIP messages from/to SIP clients 8. FIG. 1 depicts the relevant CSCFs in the establishment of a session between a roaming TE 8 (attached to a visited core network) and an AS 8b where the home core networks are separated by a Transit Network 2.
A media stream of a session is transported across a network as a bearer (packet) flow. In an IP packet environment, the bearer flow path is not automatically the same as the path traversed by the SIP signalling, because the bearer flow path it is not required to pass through nodes hosting CSCF functions. Inter domain bearer flows exit and enter administrative domains at nodes herein designated as Transport Border Gateways (TBG) 14. Again, the situation between attachment network and core network is different; the node in the core network that interfaces to the attachment network is variously called the Service Edge, Core Network Edge, Border Node, Access Media Gateway, Access Router or access network type specific terms such as GPRS Gateway Support Node (GGSN) or Broadband Remote Access Server (BRAS). In this description we will use the term Attachment Gateway (AG) 10. The AG straddles the boundary between AN 6 and CN 4.
Specifying Bearer Flow QoS Requirements
As it is known in the art, the SIP messages that initiate a session carry a description of the bearer flow (or multiple bearer flows if required) that is to be associated with the session. This description is in the form of parameters of Session Description protocol (SDP). See, for example, Handley, M. and V. Jacobson, “SDP: session description protocol”; Request for Comments 2327, April 1998. Currently the SDP part of the SIP message gives a complete description of what the bearer flow is to contain (i.e. voice or video and what codecs and bit rates to be used). This information was originally intended to enable the end systems to specify how they wanted to encode voice or video data into real time protocol (RTP) packets.
In the IMS solution, the SDP parameters may also be interpreted by CSCFs in the Various network domains interposed between the end systems, in order to determine what the bearer paths' network characteristics. Usually this information is derived from the media lines (starting with m=) the SDP. For example the last parameter in:
m=audio 8004 RTP/AVP 9
indicates an audio bearer flow that is encoded according to audio visual profile (AVP) 9, which happens to be G.722, which is a 64 kb/s stream (the network requirement has to include packet headers etc as well pushing it up to around 100 kb/s).
Based upon the SDP parameters, the CSCFs perform a process that goes by the name of connection admission control (CAC), although the process would be more accurately called Session Admission Control. The CAC process determines the resource requirements of the hearer flow(s) so that the embedded media stream(s) can be delivered with the expected QoS. If a domain does not have the resources to support a new bearer flow, then the relevant CSCF will abort the Session setup. A description of this (for p-CSCFs and AGs) is provided in the 3GPP document <<3GPP TS 23.207>>.
Traffic Classes
Traffic class is a somewhat amorphous concept that is captured by different terms in different traffic management models. In the IETF IntServ model there are three traffic classes: “guaranteed”, “controlled load”, and “best effort”. Somewhat analogously, the IETF DiffServ Model provides three types of traffic forwarding behaviors: Expedited Forwarding (EF), Assured Forwarding (AF) (although there can be up to 4 classes of AF traffic) and Default or Best Effort. ITU study groups define traffic classes for services in terms of delay and jitter (as well as throughput) plus factors such as packet loss rate and what to do with packets that are out of spec, or late.
In practical deployments of the NGN there will be a traffic class where both the delay and jitter will be the minimum possible, to be used for real-time conversations (or an operator may opt for several such classes, one for voice conversations, one for video telephony, one for gaming), and another class that guarantees throughput with bounded jitter which is suited for media stream play out (again an operator may choose to distinguish between voice and video). Since there are never any resources dedicated to best effort traffic there is little utility in using SIP to establish a best effort bearer flow, but for completeness there may be such a code point defined.
Scope of QoS Control and Treatment
FIG. 2 illustrates a bearer flow 18 divided into segments 20. Each segment 20 of a bearer flow traverses a single packet transport network 2-6 and is delimited by an end device or a gateway 14. Bearer flow segments 20 can be named by the type of network they are transported on: Attachment segment for the part, of the bearer flow that crosses the attachment network, etc.
The need to provide special treatment to bearer flow packets may not extend end to end. It is widely accepted that if a particular packet transport network is over provisioned, then the QoS treatment given to all packets will be adequate to support any particular bearer flow. Those skilled in the art will also recognize that Diffserv may be used to simulate over provisioning for specific classes of traffic. It is envisaged that some, or all, core networks will be over provisioned (or use Diffserv to simulate over provisioning for IMS packets), with the consequence that there will be no need to reserve resources for the core segments of bearer flows traversing such over provisioned core networks. However it is very likely that resources will have to be reserved for attachment segments in order to ensure that the transport of a flow's packets over those segments does not degrade the QoS of the end to end flow beneath that acceptable for the service the flow is supporting.
Resource and Admission Control Function (RACF)
The function of reserving resources for a bearer flow is closely related to admission control for the session of which the bearer flow is a constituent. If, given the current commitments to existing sessions, there is insufficient bandwidth capacity on links, forwarding capacity at nodes, or a lack of other resources needed to deliver the requested QoS for a bearer flow of a new session, then the session establishment is aborted and any resources already reserved for that session are released.
More generally, before a session is established, a number of policy decisions need to be made concerning whether to admit the session or not. In the IMS architecture these decisions originate at CSCFs, triggered by the processing of the first message in a session set up: the SIP INVITE message. The execution of some policy decisions is confined to the CSCF, but those concerning bearer flow QoS are signaled to the gateways that will handle the bearer flow, by the controlling CSCFs. FIG. 3 illustrates, for a session involving two domains, the control of the RACF function in attachment gateways (AGs) 10 and transport border gateways (TBGs) 14 by p-CSCFs and b-CSCFs respectively. Those familiar with NGN standards will recognize that in the IMS architecture, between CSCFs and Gateways, there are intermediate Policy Decision Functions (PDFs), forming the RACS (Resource and Admission Control Subsystem) network layer. As well as arbitrating between different applications requesting QoS bearer flows, a PDF may present to CSCFs an abstract view of attachment network QoS control specifics, as well as hiding the topology of AGs and TBGs.
In spite of its advantages, the NGN suffers limitations in that the route(s) traversed by Internet Protocol (IP) packets of a bearer flow is determined by conventional packet forwarding techniques, and thus may or may not follow the route traversed by the SIP messaging used to establish the flow. This provides a barrier to deployment of the NGN, as it is impossible for a network provider to properly associate IP packets traversing their network domain with a particular bearer flow, and this, in turn prevents proper billing settlements similar to those currently employed by Public Switched Telephone Network (PSTN) and cellular network operators.
Accordingly, methods and techniques that enable pinning this route of Internet Protocol (IP) Bearer Flows in a Next Generation Network remain highly desirable.